Databases are routinely upgraded to new versions, or new software patches are applied on existing versions, or the database is migrated to a new database management system. In these situations, it is typical to compare the performance of a benchmark transaction workload in the new database environment to the same benchmark transaction workload in the old database environment. A benchmark transaction workload is typically a sequence of different transactions that will “exercise” the database. To compare the performances of the benchmark transaction workloads, corresponding instances of transactions in the new and old database environments are matched, and analysis is performed between the matching transactions. When running benchmark transaction workloads for performance comparisons, it is usually desirable to run the workloads under controlled conditions. Typically, this requires that the benchmark workload is the only workload running on the system being analyzed. This usually means that system or systems must be taken out of production mode, at least while the benchmark workload is executing. In database production environments with high availability requirements, taking the system out of production mode may present a significant obstacle to performing benchmarking analysis activities.
In a typical database environment, each transaction is, for example, a sequence of one or more Structured Query Language (SQL) statements. Typically, database transactions are multi-level transactions. That is, each transaction can include several SQL statements. In addition, while the SQL log records of a transaction will usually appear in the proper order in a database transaction log file, the database operation records from multiple transactions can be intermixed. Further, the different executions of a transaction workload will typically result in different sequences of database operation transaction log file records. These factors can complicate matching of transactions between database transaction log files.